This invention relates to voice-over-Internet-Protocol (VoIP) systems, and more particularly to measurement of current bandwidth of VoIP channels on an unregulated network such as the Internet.
The widespread availability of the Internet has allowed some traditional applications such as telephone calling to use the Internet rather than traditional telephone networks. Voice-over-Internet-Protocol (VoIP) applications capture a user's voice, digitize and compress the voice, and transmit the coded voice as data inside Internet-protocol (IP) packets. The VoIP packets can be sent over the Internet like any standard IP packet.
VoIP applications can be installed on personal computers (PC's), other devices connected to the Internet, or on translation servers such as Internet-to-Telephone gateways. Each party to a call runs a local copy or client of the VoIP application. Each VoIP application captures and sends voice data, and receives VoIP packets that are decoded and played to the local user. Thus full-duplex voice calls can be made by exchanging VoIP packets between peer-to-peer client applications.
FIG. 1 is a diagram of a prior-art VoIP system experiencing packet loss. VoIP application 10 is operated by user A while VoIP application 12 is operated by user B at different nodes on the Internet. User A's speech is digitized, coded, compressed, and fitted into IP packets 20 by VoIP application 10. These IP packets 20 containing user A's voice are routed over the Internet to VoIP application 12. VoIP application 12 receives these IP packets 20, extracts and de-compresses the voice data, and plays the voice as audio to user B. User B's voice is then captured, captured, coded, compressed, and fitted into IP packets 22 by VoIP application 12. IP packets 22 containing user B's voice are also routed over the Internet back to VoIP application 10 for playback to user A. Thus a full-duplex voice call can be made over the Internet using applications 10, 12.
IP packets can be routed over a wide variety of paths using the Internet. Indeed, the de-centralized nature of the Internet allows routing decisions to be made at a number of points along the paths between applications 10, 12. The paths taken by packets 20 in the A-to-B direction can differ from the path taken by packets 22 in the reverse (B-to-A) direction. For example, packets 20 may pass through intermediate routers 14, 16, while packets 22 pass through router 18. Such non-symmetric routing can produce non-symmetric routing delays and challenges for the VoIP system.
Various network problems may occur. A router may temporarily fail, causing some packets to be delayed or lost entirely. The number of arriving packets may suddenly jump, producing congestion such as at router 18. Router 18 may delay packets 24 while the increased packet load occurs. Packets may continue to be delayed after the initial failure is fixed as the packet backlog is worked off. If the input buffers for router 18 overflow, packets 24 may be dropped or lost rather than simply delayed.
Bandwidth limitations may also occur. Packets may need to reach a user through a low-bandwidth dial-up modem line. Occasional interference may further delay packets. The modem user may send email or browse a web site, reducing further the limited bandwidth available to the VoIP application's packets. Thus bandwidth limitations may be both permanent and temporary.
FIG. 2A shows voice data that is packetized and transmitted. The user's voice can be captured as analog waves of varying frequencies that are digitized and coded. The coded voice data is divided into packets and transmitted. Sequence numbers are added to the packets to allow the packets to be re-ordered when some are delayed more than others. The sequence numbers thus allow for out-of-order reception. In this example the coded voice is divided into four packets, each packet containing coded voice data for an equal, fixed time period of 20 milli-seconds.
FIG. 2B shows packetized voice data received after varying network delays. The sequence numbers are used to re-order the packets when they arrive with varying network delays.
In this example, packet 2 is delayed slightly, causing a gap to occur between the end of playing the voice for packet 1, and the start of voice play for packet 2. A larger gap occurs between packets 2 and 3, between times 52 and 52′. These gaps may be filled in by interpolating voice data, or by adding silence. However, the pace of the user's voice may seem uneven or jerky due to such gaps.
Of course, all voice could be delayed by a large amount, such as 5 seconds, to allow for late packets. However, this requires a larger packet-input buffer and would greatly increase the delay or latency that the user hears. This delay may be noticeable to the user and annoying. Full-duplex conversation becomes impractical as the delay grows to several seconds. Thus the input buffer has a practical size limit, and packets cannot be delayed for too long.
Such gaps caused by delayed packets can reduce the quality of the voice played. When a temporary interruption occurs along the path taken by the VoIP packets, packets may pile up in buffers near the point of interruption. Should service be quickly restored, the stored packets in the buffers may be sent after some delay. However, longer-duration interruptions can cause router buffers to overflow. Packets may then be dropped or discarded before reaching their destinations.
Once the interruption ends, the older packets are likely to be sent first by the router. Newer packets may be delayed even after the interruption ends as the backlog of packets is transmitted. Thus stale packets of older voice data may be delivered before more current voice data. These older packets may already be too old to be played, resulting in a lengthening of what was a brief moment of congestion.
Detecting when such congestion occurs or when a limited bandwidth is available could be useful. Transmission of voice packets could be paused to prevent exacerbating the problem, or the user could be notified. Lower-quality voice coding could also be used to reduce the bandwidth consumed by the VoIP packets.
The sending VoIP application may be unaware of packet routing problems. The problems may not exist in packets received from the other VoIP application, as the routing paths may not be symmetrical. Even on a symmetric network congestion or limitations on bandwidth may exist only in one direction, such as upload and download directions on a cable modem. For the example of FIG. 1, VoIP application 10 cannot determine its outbound bandwidth simply by looking for delays of incoming packets received from VoIP application 12, since different routes may be taken by packets 20 sent and packets 22 received by application 10.
During initialization of a call between applications 10, 12, some provisioning may be performed to determine the initial bandwidths available between applications 10, 12. Such provisioning may be similar to fax machines that negotiate compression standards used and bandwidth or baud rate for each call. However, changes to the Internet that later occur during the call are not detected once provisioning is over and the call is started.
What is desired is a VoIP application that can detect network problems such as congestion, limited bandwidth, and delays. A VoIP system that separately measures bandwidth for forward and return paths is desirable. A VoIP application that continuously monitors network conditions is desired.